"Props Drilling 지우기" 글과 관련해서 의견을 나누고 싶어요. #29
Replies: 4 comments 3 replies
-
|
안녕하세요 @jungpaeng 님, 소중한 의견 남겨주셔서 감사해요!
예시) <ContextProvider>
<MemorizedParentComponent>
<ChildComponentUsingContext /> <- 값이 변경되면, 해당 컴포넌트만 리렌더링이 됩니다.
</MemorizedParentComponent>
</ContextProvider/>
제안주신 예시를 사용하면, 오해를 줄이고, 메세지가 효과적으로 전달될 것 같은데요. |
Beta Was this translation helpful? Give feedback.
-
@Kimbangg 이 부분에 대해서 혹시 어떤 게 잘못된 인식이라고 생각하는지 알 수 있을까요? ContextAPI는 전달 통로 역할을 하기 때문에 props drilling을 해결하기 위해서 Context API를 사용하는 것은 어색하지 않을 것 같아요. 공식 문서에서도 props drilling 문제를 해결하기 위해서 ContextAPI 사용을 제시하고 있기도 하고요. 잘못된 인식을 생각해보면 그렇지만 남겨주신 예시 코드를 보면 이것을 우려한 것은 아니고 Context의 영향 범위가 아닌 코드가 리렌더링되는 것에 대해서 우려하고 계신 것 같아요. 이게 맞다면 저는 이 부분에 대해서는 '크게 걱정할 부분이 아니다' 라고 생각해요. 이렇게 생각한 부분에 대해서는 여러 이유가 있는데요.
또한, dan abramov를 비롯한 많은 리액트 / 프레임워크 개발자들이 리액트의 재조정 단계는 매우 빠르며, 이는 무시할만한 수치라고 의견을 남기기도 했어요(이제 다시 와서 재조정 횟수를 가지고 퍼포먼스 측도를 판단하는 흐름이 찾아오고 있는 것 같지만..). ContextAPI가 redux, zustand, jotai와 비교되면서 '리렌더링을 더 많이 발생시키는 안 좋은 기능'이라고 평가 받는 것도 많이 봐왔지만 대부분은 오해라고 생각하기도 하구요. |
Beta Was this translation helpful? Give feedback.
-
|
@jungpaeng 님, 상세한 답변 정말 감사합니다.
말씀 주신 대로 “리렌더링”이라는 표현을 넓게 사용하다 보니 이런 오해가 생겼던 것 같습니다. :)
질문으로 돌아가, “Props Drilling 해결 = Context API 사용”이 잘못된 인식이라고 생각했던 이유를 곰곰이 돌아보았습니다. 위 예시와 같이, 부모 컴포넌트가 1~2개의 자녀를 가지는 경우에는 말씀하신 대로 성능에 큰 영향을 미치지 않을 것 같습니다. 따라서 Context API 사용 자체에 대한 반감을 키우고 싶다기 보다는, 해당 글을 통해 Context API를 언제, 어떻게 사용하는 것인지 함께 다뤄볼 수 있으면 더더욱 좋을 것 같습니다. @jungpaeng 님께서 가지고 계신 생각을 명확하고 이해하기 쉽게 전달해 주셔서 감사드립니다. |
Beta Was this translation helpful? Give feedback.
-
저도 props drilling을 무분별하게 Context API로 대체하는 건 잘못됐다고 생각해요! 이러한 부분을 주의하라고 작성해볼 수 있을 것 같아요.
저는 이 경우에도 대부분은 문제가 되지 않을 거라고 생각해요. 실제로 제가 만들었던 서비스 중, 서명 에디터가 있었는데 drag & drop, 꽤 많은 인터렉션, 복잡한 구조로 인해서 많아지는 컴포넌트로 복잡도가 꽤 있는 서비스였어요. 그럼에도 저는 ContextAPI를 적극적으로 사용했고 useMemo, useCallback, memo 등과 같은 메모이징을 일절 하지 않았음에도, 실제 사용자 환경과 유사한 사양으로 진행했을 때에도 퍼포먼스 이슈를 겪지 못했어요. 심지어 drag & drop을 할 때, mousemove 이벤트를 throttle 처리하지도 않아서 정말 수많은 이벤트와 화면 업데이트가 진행됐고 그 사이에 리액트 재조정이 무수히 많이 일어났을 것임에도 문제가 되지 않았죠. 사실 리액트의 재조정 단계는 정말 매우 빨라요. 저사양 기기에서도 리액트 재조정이 무리없이 매우 빠르게 돌아가서 무시할 수 있을 정도로요. 그럼에도 리렌더링을 개선했더니 서비스 속도가 빨라졌다는 후기 또한 많이 있어요. 왜 이런 차이가 발생할까? 를 생각해봤을 때, 저는 서비스 내에 무거운 로직이 있고 그 무거운 로직이 매 렌더링마다 다시 실행되는 게 속도 저하를 크게 발생시킬 거라고 생각해요. 그러면 여기에서 서비스 속도를 개선하기 위해 선택할 수 있는 방법은 두 가지라고 생각해요.
당연히 좋은 방법은 1번이라고 생각해요. 이 내용에 관해서 좋은 글이 있어요. 렌더링을 줄이기 전에 렌더링을 느리게 만드는 것을 해결하라는 글이에요. https://kentcdodds.com/blog/fix-the-slow-render-before-you-fix-the-re-render 하지만 어렵죠. 그렇기 때문에 메모이징과 같은 기법이 있고요. 그리고 지금에 와서는 왜 렌더링을 줄이는 선택을 했는지에 대한 것은 많이 잊어버리고, 렌더링은 많으면 안 되는 것이라는 분위기가 다시 형성된 것 같기도 해요. 적다보니 말이 다른 곳으로 샌 것 같은데, 아무튼, 정리를 해보면 저는 ContextAPI를 사용하는 것은 크게 문제가 되지 않는다. 이렇게 볼 수 있을 것 같아요. 그렇지만, 모든 상태를 ContextAPI로 저장하는 등의 불상사는 벌어지면 안 되기 때문에 사용해야 할 시점을 잘 정리해서 제공해야 한다는 저도 너무 공감해요. |
Beta Was this translation helpful? Give feedback.
-
막상 개선 작업을 시작하면 불필요한 렌더링을 줄이는 작업들을 우선적으로 진행 해왔던 것 같아요. 뿐만 아니라, 일반적으로 가지고 있는 오해들에 대해서 오늘처럼 깊게 고민해봤던게 정말 오랜만인 것 같아요. 덕분에 많이 배워갑니다 bb. |
Beta Was this translation helpful? Give feedback.
-
|
아! 그리고 Context API 예시도 꼭 추가 부탁드립니다. 다른 분들도 예시를 보면서 많이 배워 나갈 수 있을거라 믿어요. |
Beta Was this translation helpful? Give feedback.
-
|
전역 상태에 관한 열띈 토론이 이어지고 있네요 👀 |
Beta Was this translation helpful? Give feedback.
Original comment in Korean -
위 문구가 의도한 바는 "코드 상에서 props의 정보가 수정되면, 이를 참조하는 모든 컴포넌트의 코드 수정이 이뤄져야 할 것이다"라고 생각돼요.
다만, "props의 값이 변경됐을 때 이를 사용하는 모든 컴포넌트가 다시 렌더링(변경)된다" 라고 해석될 수 있을 것 같아요.
요즘 다시 리액트 리렌더링은 무조건 피해야 한다는 오해가 다시 생기고 있는 것 같아서 명확한 표현으로 변경되면 좋지 않을까? 생각하게 되었어요.
'개선해보기' 에서
ContextAPI를 사용하는 것이 추가되는 게 좋을 것 같아요.Composition을 사용했을 때 컴포넌트 구조가 보다 더 flat하게 변경되면서 어느정도 해소되겠지만, 완벽히 해소될 수는 없을 것 같아요. 컴포넌트의 구조를 변경하는 것도 좋겠지만 가장 빠르고 확실한 해결책은
ContextAPI라고 생각이 돼요.composition 개선 예시 코드에서도 의견을 나누고 싶은데요!
composition 패턴에 익숙하지 않은 분들은 composition에 작성된 전 후 코드 비교를 보고 "별도 컴포넌트를 나눠서 props를 다시 전달하는 것보다 컴포넌트 내용을 다시 적는 게 props 넘기는 절차를 줄여도 되니 더 효과적이구나" 라고 오해할 수도 있을 것 같아요.
아래 코드처럼 별도 컴포넌트를 나누되,
children을 사용해서 props drilling을 줄이는 예시로 보여주면 어떨까 생각되어요.Beta Was this translation helpful? Give feedback.
All reactions